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REMARKS 

Claims 11, 14, 15, 54, 57, 58, 89, 90, 96, and 97 are amended, claims 1-10, 
17-53, 60-88 91-95, and 98-100 are canceled, and claims 101-104 are new. Claims 
11-16, 54-59, 89, 90, 96, 97, and 101-104 are pending in this application, with claims 
11,14, 54, 57, 89, 90, 96, and 97 being in independent form. 

In the Office Action 1 , the Examiner took the following actions: 

rejected claims 13 and 56 under 35 U.S.C. § 1 12, second 
paragraph; and 

rejected claims 11-16, 54-59, 89, 90, 96, and 97 under 35 
U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 
6,285,777 to Kanevsky et al. ("Kaneysky"). 

REJECTION OF CLAIMS 13 and 56 UNDER § 112 

Applicant respectfully traverses the rejection of claims 13 and 56 under 35 U.S.C. 
§112, second paragraph. The Office Action alleges that the limitation "wherein the 
static address database is a United States Postal Service static monolithic address 
database" is vague and indefinite because "it is unclear to the Examiner what 
'monolithic' means as used in the claimed invention." Office Action at 3. Applicant 
asserts that one having ordinary skill in the art would appreciate the meaning of this 
claim term in view of Fig. 1 1 B of the pending application and the discussion at pages 
23-24 of the Specification. For example purposes only, Applicant provides the attached 
"Introduction to Database Management: VII. Database System Architecture" document 
available at http://www.cs.uwaterloo.ca/-gweddell/cs448/Arch.pdf (last visited May 27, 

1 

The Office Action may contain a number of statements reflecting characterizations of the related art and 
the claims. Regardless of whether any such statement is identified herein, Applicants decline to 
automatically subscribe to any statement or characterization in the Office Action. 
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2008), in which "monolithic" is used in connection with databases. Accordingly, 

Applicant requests the Examiner to reconsider and withdraw the rejection of claims 13 

and 56 under 35 U.S.C. § 112. 

REJECTION OF CLAIMS 11-16. 54-59, 89, 90. 96. and 97 UNDER § 103(a) 

Applicant respectfully traverses the rejection of claims 11-16, 54-59, 89, 90, 96, 
and 97 under 35 U.S.C. § 103(a) as being unpatentable over Kanevskv . A prima facie 
case of obviousness has not been established. 

The key to supporting any rejection under 35 U.S.C. § 103 is the clear 
articulation of the reason(s) why the claimed invention would have been obvious. See 
M.P.E.P. § 2142, 8th Ed., Rev. 6 (Sept. 2007). Such an analysis should be made 
explicit and cannot be premised upon mere conclusory statements. See id. "A 
conclusion of obviousness requires that the reference(s) relied upon be enabling in that 
it put the public in possession of the claimed invention." M.P.E.P. § 2145. Moreover, 
"[i]n determining the differences between the prior art and the claims, the question 
under 35 U.S.C. § 103 is not whether the differences themselves would have been 
obvious, but whether the claimed invention as a whole would have been obvious." 
M.P.E.P. § 2141.02(1), internal citations omitted (emphasis in original). 

"[T]he framework for the objective analysis for determining obviousness under 35 
U.S.C. 103 is stated in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ459 (1966). 
. . . The factual inquiries . . . [include determining the scope and content of the prior art 
and] . . . [ascertaining the differences between the claimed invention and the prior art." 
M.P.E.P. § 2141(11). "Office personnel must explain why the difference(s) between the 



-11- 



Attorney Docket No. 08049.0006-00000 
Application No. 09/809,326 

prior art and the claimed invention would have been obvious to one of ordinary skill in 

the art." M.P.E.P. § 2141(111). 

As amended, independent claim 1 1 recites a method for method for determining 
a standardized physical address of a user comprising, among other steps, "creating a 
static address database from a master address database, the static address 
database containing the standardized physical address of the user, wherein the 
standardized physical address conforms to a standard format." (emphasis added). 

Kanevskv discloses "[a] communication system that transmits and receives 

combinations of paper mail and electronic mail." Kanevskv at Abstract. In the 

Kanevskv system, "database means 108 contains all addresses of senders and 

recipients that were recorded at a given time. Database 108 also indicates what 

addresses of senders/recipients were simultaneously on one envelope/letter." 

Kanevskv at column 5 lines 49 through 52. According to Kanevskv , 

The ascii files 104, 106 are sent to a comparator means 1 10 
where it is determined whether similar information 
(representing one or all of items of the ascii files 1 04, 1 06 
are stored in the database of sender/receive communication 
means 108. If it determines that some sender or receiver 
addresses match in most of characters to a decoded 
addresses from the files 104, 106 this information is sent to a 
corrector means 112. Corrector means 112 corrects the 
address from the 104 or 106 files. For example, a correct 
written e-mail address 92 is smith@nesctr.com and 
destination address 96 is Jones@westch.com If the e-mail 
addresses in 104 and 106 were decoded as 
smith@resctus.com and Jones@westu.com. If Smith sent 
messages to Jones in past, these addresses were recorded 
in the database 108 and related. This information can be 
used in corrector means 1 12 to correct the addresses in 104 
and 106. 

Kanevskv at column 5, line 55 through column 6, line 4. 
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Although Kanevskv teaches "database means," Kanevskv fails to teach or 

suggest "creating a static address database from a master address database, the 

static address database containing the standardized physical address of the user." In 

addition, Kanevskv 's "corrector means ... to correct the addresses" teaches address 

error correction, at best, and does not teach or suggest that "the standardized 

physical address conforms to a standard format," as recited in claim 1 1 . Moreover, 

Kanevskv does not teach or suggest the use of an "electronic account" as is recited in 

claim 11. 

Accordingly, Kanevskv does not teach or suggest all of the elements of 
independent claim 1 1 . Moreover, nothing in Kanevskv would motivate or suggest to 
one of ordinary skill in the art to modify the teachings of Kanevskv to achieve the 
claimed combination. In view of the above, the Office Action has neither properly 
determined the scope and content of the prior art nor properly ascertained the 
differences between the prior art and the claimed invention. Consequently, the Office 
Action has failed to clearly articulate a reason why the claim would have been obvious 
to one of ordinary skill in view of the prior art. Therefore, a prima facie case of 
obviousness has not been established for at least the reasons discussed above and the 
Examiner should withdraw the rejection of independent claim 1 1 under 35 U.S.C. § 
103(a). 

Independent claims 54, 89, and 96, although of a different scope from claim 1 1 
and from each other, include recitations that are similar to those discussed above in 
connection with claim 1 1 . Accordingly, a prima facie case of obviousness has not been 
established for claims 54, 89, and 96 for at least the same reasons discussed above. 
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Claims 12-13 and 55-56 depend from one of allowable independent claims 11 and 54 , 

and are allowable at least due to their dependence. Therefore, for at least these 

reasons, the Examiner should also withdraw the rejection of claims 12-13, 54-56, 89, 

and 96 under U.S.C. § 103(a). 

As amended, independent claim 14 recites a method for determining a 

standardized physical address of a user comprising, among other steps, "accessing an 

address database containing the standardized physical address of the user, wherein the 

standardized physical address conforms to a standard format." As discussed above in 

connection with claim 1 1 , Kanevskv does not teach or suggest that "the standardized 

physical address conforms to a standard format," as recited in claim 14. Moreover, 

Kanevskv does not teach or suggest the use of an "electronic account" as is recited in 

claim 14. 

Accordingly, Kanevskv does not teach or suggest all of the elements of 
independent claim 14. Moreover, nothing in Kanevskv would motivate or suggest to 
one of ordinary skill in the art to modify the teachings of Kanevskv to achieve the 
claimed combination. In view of the above, the Office Action has neither properly 
determined the scope and content of the prior art nor properly ascertained the 
differences between the prior art and the claimed invention. Consequently, the Office 
Action has failed to clearly articulate a reason why the claim would have been obvious 
to one of ordinary skill in view of the prior art. Therefore, a prima facie case of 
obviousness has not been established for at least the reasons discussed above and the 
Examiner should withdraw the rejection of independent claim 14 under 35 U.S.C. § 
103(a). 
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Independent claims 57, 90, and 97, although of a different scope from claim 14 
and from each other, include recitations that are similar to those discussed above in 
connection with claim 14. Accordingly, a prima facie case of obviousness has not been 
established for claims 57, 90, and 97 for at least the same reasons discussed above. 
Claims 15-16 and 58-59 depend from one of allowable independent claims 14 and 57, 
and are allowable at least due to their dependence. Therefore, for at least these 
reasons, the Examiner should also withdraw the rejection of claims 15-16, 57-59, 90, 
and 97 under U.S.C. § 103(a). 
NEW CLAIMS 101-104 

Applicant respectfully requests consideration and allowance of new claims 
101-104. Support for new claims 101-104 can be found at, for example, page 21, line 
13 through page 22, line 2. 
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CONCLUSION 



In view of the foregoing amendments and remarks, Applicant respectfully 
requests reconsideration and reexamination of this application and the timely allowance 
of the pending claims. 

Please grant any extensions of time required to enter this response and charge 
any additional required fees to our Deposit Account No. 06-0916. 



Respectfully submitted, 



FINNEGAN, HENDERSON, FARABOW, 
GARRETT & DUNNER, LLP. 





Reg. No. 27,432 
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Introduction to Database Management 



Architecture 



VII. Database System Architecture 

Lecture Topics 

• Monolithic systems 

• Client/Server systems 

• Parallel database servers 

• Multidatabase systems 
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Each component presents a well-defined interface to the component 
above. 
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Introduction to Database Management 



Architecture 



Component Functions 



Applications 

- User interaction: input of queries and data, display of 
results 

- Application-specific tasks 
The DBMS 

- Query optimization: selection of one of many possible 
procedures for executing a query 

- Query processing: execution of the selected query 

- Buffer management: allocation and control of memory 

- Transaction management: concurrency control, rollback, 
and failure recovery 

- Security and integrity management: access control and 
consistency checking 

The File System 

- Storage and retrieval of unstructured data 
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Introduction to Database Management 



Architecture 



Client/Server System (cont.) 



• DBMS Client: packs application requests into messages, sends 
messages to server, waits for and unpacks the response 

• DBMS Server: all database system functions, including query 
processing and optimization, transaction management, security 
and integrity management, buffer management 



Client/server separation allows user interaction and 
database management to be performed by different 
processors 
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Parallel/Distributed Database Server 
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Architecture 



Parallel/Distributed Database Server (cont.) 

• Data is distributed across the sites 

• Relations may be fragmented 

• Relations (or fragments of relations) maybe replicated at several 
sites 



Component servers are intended to operate 
as a team, not independently. 

• A single, common schema 

• Distribution of data is transparent 

• Distribution of computation is transparent 

• Replication is transparent 

• Fragmentation is transparent 
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Architecture 



Parallel vs. Distributed 

• Parallel Database Server 

- servers in physical proximity to each other 

- fast, high-bandwidth communication between servers, 
usually via a LAN or shared memory 

- queries often processed cooperatively by all servers 

• Distributed Database Server 

- servers may be widely separated 

- server-to-server communication may be slower, possibly 
even via a WAN 

- queries often processed by a single server 
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Introduction to Database Management 



Architecture 



Parallel/Distributed: Why? 



• Reliability and Availability: if one server fails, another can take 
its place 

• Faster Query Processing: several servers can cooperate to 
process a query 
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Introduction to Database Management Architecture 



Horizontal Fragmentation 

Complete relation: 
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Vertical Fragmentation 

Complete relation: 
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Data Distribution 

Relations (or fragments) 
Rl R2 
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Architecture 



Data Replication 



Relations (or fragments) 
Rl R2 
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Architecture 



Multidatabase System 



• Application perceives a single database system 

• Database systems are autonomous 
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Multidatabase System w/ Gateway 
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